The—so called—Internet Protocol Multimedia Subsystem, IMS, is currently standardized by the 3rd Generation Partnership Project (3GPP). In short, the IMS comprises a technology that allow multimedia communications originated/terminated/involving users subscribed to the IMS, and wherein some of the servers belonging to the IMS are arranged to process the services of these users according to the Service Profile (SP) that is correspondingly configured in respect to these users. In a minimal implementation—i.e. taking into account what it is currently defined by the 3GPP Specifications defining the IMS, the SP of a user comprises at least one “Public Identifier” of the user.
Some of the relevant 3GPP Specifications defining the IMS, and defining how services related to a user are dealt with according to the SP data of their corresponding SP, are:                3GPP TS 23.218 (which is a stage-2 specification defining a model for handing signaling of services in a IMS),        3GPP TS 23.228 (which is a stage-2 specification defining functional entities in the IMS, their basic processing, and their interfaces), and        3GPP TS 29.228 (which is a stage-3 specification defining protocol details for implementing the—so called—“Cx” interface between a HSS and a S-CSCF, and for structuring and coding therein the data making up the SP).        
According to the 3GPP specifications defining the IMS, a service involving a user of the IMS is to be controlled—among others—by a Serving Call Session Control Function server (S-CSCF), which is assigned to process the signaling of services originating and/or terminating in said user, and which has received from a Home Subscriber Server (HSS) the SP of said user (i.e. according to the SP data received in respect to said SP). In short, the S-CSCF will process the services involving said user according to the values of the SP data received from the HSS for said user; wherein said services comprise e.g.: services originated by a terminal of said user, services terminating in a terminal of said user, or—more generally—terminating in said user; for example in case the S-CSCF receives a signaling message requesting a service addressing a public identifier of said user (e.g. a Session Initiation Protocol message “INVITE” comprising a SIP-URL of said user) but there is not a terminal for said user registered when the message is received.
Therefore, the controlling of services in a IMS depends to a high extent on the data configured in respect to SP's, both, in a HSS and in a S-CSCF; wherein said controlling comprises, on the S-CSCF, processing the services originated/terminated services of a user according to the data of said SP's.
More specifically, the controlling of services of a certain user in a IMS comprises:                configuring in the HSS a service profile, SP, in relationship with the subscription to the IMS of the user, the SP comprising a set of SP data usable by the S-CSCF for processing of services of said user,        transmitting the SP data from the HSS to a S-CSCF, and        controlling by the S-CSCF the processing of services of the user according to the SP data values received from the HSS.        
It is to be noticed herein that the expressions “terminal” (of a user)” or “user terminal”, which are used along the present application, do not refer to terminals necessarily operated by human users.
The FIG. 1 shows a simplified view of an architecture of a IMS, illustrating some kind of servers and their interfaces according to what it is defined by 3GPP specifications. In particular the FIG. 1 corresponds to FIG. 5.2.1 of 3GPP TS 23.218, and further comprises some reference numerals and noted interfaces.
The illustrated IMS comprises a HSS server (9100) and a S-CSCF server (9200). The IMS can also comprise, as illustrated in FIG. 1, an Application Server, AS (9300), that can belong to the network domain of the operator owning the IMS, or that can be outside said network domain (e.g. belonging to a service provider who is not the network operator providing the IMS). In short, an AS (9300) can be a server implementing service processing logic for processing the signaling of an originating and/or terminating service involving a user of the IMS. Said AS logic can comprise, for example, diverting an originating call to a certain destination after a certain time, play a pre-recorded announcement towards the originator, rerouting unconditionally an originating call to a certain destination, etc.
For the sake of simplicity, only one instance of each kind of server (9100, 9200, 9300) is illustrated by FIG. 1; however, it is apparent that more than one instance of each of the illustrated servers may exist on a real implementation of a IMS.
The HSS (9100) and the S-CSCF (9200) communicates via the so called “Cx” interface (9192). Details of the “Cx” interface (9192) are disclosed by 3GPP TS 29.228. Using the “Cx” interface the HSS sends to the S-CSCF the SP data making up the SP of a user.
Using the “Cx” interface, therefore, the S-CSCF is thus be able to receive said SP data and, consequently, use these SP data for processing the services that involve said user. For example, this involves the S-CSCF processing the services that are originated or terminated by a user identified by said SP (e.g. signaling messages comprising a Public Identifier contained in said SP—at least one Public Identifier is defined by the SP of a user). For example, this also involves the S-CSCF processing a service terminated by a user identified by said SP even if there is not a user terminal registered for said user (e.g. signaling messages comprising a Public identifier contained in said SP when the registration status of said user is e.g. “unregistered”).
An S-CSCF (9200) can communicate with a AS (9300) via the—so called—“ISC” interface (9392). The functionality of the “ISC” interface (wherein ISC stands for “IP multimedia Service Control”) is described e.g. by the aforementioned 3GPP Specification 23.218, and it is commonly based on Session Initiation Protocol, SIP, protocol signaling.
A quite common AS is—as contemplated by the aforementioned 3GPP Specification 23.218—a SIP-AS. In short a SIP-AS is arranged to process the SIP signaling due to originating and/or terminating services of a user by receiving and/or sending SIP signaling messages e.g. from/to the S-CSCF assigned to said user in the IMS. A common use—cited herein as an illustrating example—comprises a (SIP-) AS arranged to: receive a message in relation to a service from/to a user (e.g. receiving a SIP message), changing some data contents of the received message—i.e. by applying its specific service processing logic-, and then sending (e.g. to a S-CSCF) the message with the modified contents. This particular case is illustrated by FIG. 2, which corresponds to FIG. 9.1.1.4.1 of the 3GPP TS 23.218.
Additionally, or alternatively, another example can comprise a (SIP-) AS arranged to: receive a message in relation to a service (e.g. receiving a SIP request message), and—by applying its specific service processing logic—generating and further send a different SIP message (e.g. a SIP response message). One example of this is provided in FIG. 6.3.1 of the 3GPP TS 23.218.
The rules governing the conditions for controlling a service in a S-CSCF that makes it to process a service so as to send a received message towards an AS—e.g. a SIP message via the “ISC” interface—are dictated by the so called “IFC” (“initial Filter Criteria”; FIG. 1: 9210), commonly referred along the 3GPP Specifications also as “IFC” or “iFC”. More specifically: the processing of a service related to a user by a S-CSCF based on the IFC(s) that belong to the SP of the user is briefly described within the chapter 5.2.3 of the aforementioned 3GPP TS 23.218, whilst the eventual data contents of an IFC are detailed by the aforementioned 3GPP TS 29.228 (e.g.: in Annex B.2.2—in particular by figure B.2.2.1.1-, and in Annex E—in particular in Table E.2). In short, the SP data that is downloaded to a S-CSCF from a HSS in respect to the SP of a user can comprise instances of IFCs, which content/s are going to determine in the S-CSCF how the signaling due to a service involving the concerned user is to be processed, and when a given AS is to be contacted from the S-CSCF via the ISC interface (e.g. as determined by the AS identified by the corresponding IFC's content) and, in sum, determining by the S-CSCF the control of a service in the IMS relating to said user based on the SP data received from the HSS. However, as stated earlier, the SP of a user does not need to contain IFCs, in which case the S-CSCF will control the services of a user by processing the related messages (e.g. SIP protocol messages) according to its own configured logic.
In view of the IMS related prior art cited above, it is apparent that a telecommunications system comprising a IMS may provide many advantages when coming to the issue of providing users with communication services. This is achieved by e.g. providing a user subscribed to the IMS with a SP comprising SP data for controlling the services they originates and/or terminates. In particular, the controlling of said services can comprise forwarding the signaling messages due to any of these services from the S-CSCF to another party; for example, forwarding them to an AS.
As mentioned earlier, the ASs with which a S-CSCF of a IMS may interact can belong to the network domain of the network operator handling the IMS, or can belong to a different domain; for example, they can belong to the network domain of a third party—e.g. with which the network operator of the IMS has subscribed an agreement in respect to the control of services of some of their subscribed users-.
In either case, the AS(s) that can could be contacted by a S-CSCF, as well as any other kind of terminal or server that could be contacted by a S-CSCF for accomplishing with the controlling of a service according to the SP data of a user involved/concerned by the service, may be subject or particular characteristics and/or circumstances, either: static or dynamic. Said characteristics and/or circumstances comprising, for example: capacity and availability.
Therefore, it should be desirable to devise mechanisms that, while complying with the basic frameworks defined by 3GPP specifications in respect to how services are to be controlled in IMS, allow in a more flexible manner the controlling of said services taking into account information about the parties that can be involved in a service. In other words, it should be desirable to get a more flexible handling of services in a IMS.